DHCP Relays
Referring now to FIG. 1, we present the principle of operation of a DHCP relay within an operator's communications network.
Telecommunications operators use the DHCP protocol to assign IP addresses to the terminal apparatuses of their customers and/or to the modem-router in order to establish connectivity with their network and thus provide certain services (Internet access, videoconferences, voice-on-IP, digital television, video on request, etc).
The DHCP relay 10, as defined in the document RFC2131 (document describing the DHCP by the IETF or Internet Engineering Task Force which is the protocol standardization organization in the Internet world), plays a role in DHCP messages broadcast by Ethernet. The main goal of this relay is to extend the range of action of the broadcast DHCP messages beyond the client's local area network (LAN) 100. Thus, through the DHCP relay 10, the client (using apparatuses forming his network, 101, 102, 103, 104) can send out general broadcast messages, the DHCP relay 10 acting to link up the client's local area network with the operator's network 101.
The chief use of a DHCP relay 10 therefore is to set up a gateway/router from the client's LAN 100 relaying the DHCP messages sent out on this local network to a second LAN 101 (that of the telecommunications operator) in which the DHCP server is situated, thus enabling physical separation between the client, operator network and ISP (Internet Service Provider) networks.
The DHCP relay 10 is therefore an apparatus forming part of the operator's administrative domain. It is situated on the boundary of the network 101 (as in the case of the DSLAM or Digital Subscriber Line Access Multiplexer) or right within the network 101 (as in the case of a BRAS or Broadband Remote Access Server or router when the client's circuit is extended or permutated up to this apparatus).
The function of a DHCP relay is very widely used by operators to relay DHCP messages from the clients LAN (which has the apparatuses 101, 102, 103, 104) to one or more DHCP servers 1011, 1012 situated in the operator's network.
It is a physical element of the operator's network, that acts as a DHCP relay 10. In general, it is the IP node (the router) closest to the client which has this relaying responsibility (as in the case for example of the DSLAM collecting client traffic).
The client's local area network (through the modem) can be attached to the DHCP relay by means of a physical interface sub-divided into logic sub-interfaces such as VCs (virtual channels), ATM (Asynchronous Transfer Mode) interfaces or VLANs (Virtual Local Area Networks).
In the network element in which the DHCP relay function is implanted, it is in the IP configuration of each logic sub-interface (1001, 1002, 1003, 1004) that the link is set up with a DHCP address pool which will be used to serve the client in the context of this sub-interface. In other words, each logic sub-interface (1001, 1002, 1003, 1004) assigned to the client's local area network in the DHCP relay 10 has an IP address that serves as a link with the IP addresses assigned in the local area network 100, these addresses being assigned to the modem or to the apparatuses 101, 102, 103, 104. Thus, a client having a local area network in which four services are launched (through four apparatuses 101, 102, 103, 104) corresponding to four logic sub-interfaces (1001, 1002, 1003, 1004) will have four IP addresses available assigned by means of the DHCP protocol.
Pool Selector
Several pools can be declared in the DHCP server. They enable the addressing of different services (Internet access, videoconferencing, voice-on-IP, digital television, video on request, etc) calling for distinct IP addressing planes. The DHCP server acts as a pool selector for the assigning of IP addresses.
As a rule, the DHCP relay apparatus gives the DHCP server an indication of the pool to be selected by means of the “giaddr” DHCP field of the DHCP request. This field identifies the address of the gateway. The “giaddr” field is updated by the DHCP relay upon an IP address assignment query sent by an apparatus of the client's local area network. The apparatus relays the query to the DHCP server in entering information into the giaddr field which subsequently acts as a pool selection indicator with the DHCP server (as described in the standardization document RFC2131).
The DHCP server then determines the pool in which it will serve the client. This selection can be done according to several criteria. However, the first criterion taken into account by the pool selector (the DHCP server) is generally the “giaddr”.
According to the strategy, the DHCP server can choose any unoccupied address in the pool (the first unoccupied address for example) or use additional criteria such as the MAC address (machine address) or the client line identifier to restrict the choice to a range of addresses or to precisely one address.
It can be seen therefore that the “giaddr” field plays a dual role:                a role of IP connectivity between the DHCP relay and DHCP server. Indeed, the “giaddr” address should be “routable” on the IP network because the DHCP server responds to the DHCP relay located at the giaddr IP address.        a pool selection role. The “giaddr” and the pool belong to the same IP sub-network or subnet; it is thus that the DHCP server recognizes the pool indicated and selects it.        
The IETF (Internet Engineering Task Force) has also defined possibilities of indicating the pool, by creating new indicators positioned by the client (“Subnet Selection Option” as set forth in the RFC3011) or by the relay (Link Selection Option under the RFC3527). In these modes of operation, the “giaddr” field loses its pool indicator role.
It can therefore been seen that the link between the IP configuration of an interface and the DHCP pool that would be used to serve the client is set up mainly by the “giaddr”.
Drawbacks of the Prior Art
A major drawback of this prior art technique is that the IP configuration of each interface is statically linked to the pool. It may be recalled that an interface of the client's local area network is linked to one or more services (Internet access, videoconferencing, voice-on-IP, digital television, video on demand, etc). Consequently, the configuration of each service is linked to the pool. Indeed, each interface is statically attached by configuration to a “giaddr” value and is therefore statically attached to a particular pool since this it is the value of “giaddr” that is used by the DHCP server to select the pool in which it will serve the client.
A corollary drawback of this prior art technique is that the address pools are assigned statically, giving rise to substantial over-consumption of IP addresses. This is a problem when the addresses are IPv4 public addresses whose number is extremely limited.
This over-consumption may be due to many factors, among them:                the small proportion of logged-in clients (clients connected and using the service) as compared with the number of connected clients (clients who are subscribers to the service but have not activated it at an instant t).        the gradual connecting-up of new clients.        
Indeed, since each address pool can be linked to a service (for example an Internet access pool, a videoconferencing pool, a voice-on-IP pool etc), each of these pools must contain enough addresses to meet the needs of all the clients who have subscribed to services. For example, if 2000 clients have subscribed to the Internet access service, the pool in charge of this interface must contain at least 2000 addresses. This is so even if only a few clients (for example 200 clients) can be logged in simultaneously to the service at a given point in time. In this example therefore there is a very substantial level of unnecessary consumption of addresses.
As for the gradual connection of new clients, the prior art technique also raises problems since it necessitates the manual re-definition of the sizes of the pools according to the arrival of the new clients or again according to subscription to new services by existing clients. Thus, if a 2001st client wishes to access the Internet access service, then the pool in charge of this interface must be configured so that it contains at least 2001 available addresses. This is especially so as additions to pools are done in increments big enough to prevent repetition of these operations. This reconfiguration (which is a manual operation) proves to be cumbersome in that it increases the client's waiting time before he can access the desired service.
To overcome these phenomena of over-consumption of IP addresses, a dynamic address allocation method is proposed in the document U.S. 2005/097223. However, this method of allocation is implemented in DHCP relays, making the assigning of the addresses relatively inefficient and complicated.